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Description 

Fieidof the invention 

5 This invention deals with approval on contents of electronioalty generate and mailed documents and with a system 

for generating, monitoring and processing said documents. 

Background of Invention 

10 Electronic maHing systems are now currently used wfthin an increasing number of companies. Such a system 

enables users to exchange very quickly a lot of information using simple notes or nriore elaborate documents. 

But documents which must be signed or approved are in most cases handled the archaic way So every step in 
the process involves human inten/ention. The originator of the document must have a copy of the form, He gets copies 
of lomi from central stores which have to be administrated. Often he keeps copies for later use and risks using an 
?5 outdated version of the form. When filling-ln the form very little help is available and of course no error checking can 
be done. The form can often be confusing and difficult to complete, because cc^t consideratbns lead to the creatic^ 
o1 multipurpose forma which can be used In all instances. A more elaborate form filling system has been disclosed in 
European applicatic^ No. 0,269,875 wherein shed forms are processed. 

Once the form is completed, the originator has to get it approved. The approval process can be simple (for Instance 
20 approval by the originator's nnanager), in that case, a simple electronic mail forwarding operation would do the jct). 

But in most instances the requirements are more complex and several levels of management or functional approv- 
als may be required, e.g. by a Financial Analyst, a Budget Cc^troHer, etc... Often the approval process depends cm 
data filled into the form: e.g, for a purchase order 11 the amount of a purchase requested doesn't exceed a grven value, 
erne level of management is sufficient, otherwise two levels of management are n^essary, for instance. Also because 
25 of management decisions, approval rules for a given form can be changed without the form itself being changed. 

With a conventional system, when the originator passes the document to the first approver (e.g. his manager) to 
get his signature (i.e. approval), ha has tost control of it. He cannot be sure where the document is or who has it or if 
the document Is hand carried or forwarded through Internal mail. This prevails for any step in the approval process : 
first approver looses control upon transferring the dccument to the second approver and so on. Often approvers have 
30 to keep a paper copy of the document before passing it to the next approver. 

In some instances approval has to be given by a delegate, but people may not know who the delegate is. 
The approver list may also need to be modified during the approval process : an approver can be replaced by his 
manager the order of approval can be changed or more informatioi may be requested by an approver from another 
approver who has already signed. 
^ Finally, al! documents issued from forms and approved reach the person or the department who has to process 

and execute the request. First, checking must be done : data checking and approval process checking. 
Then, if all is correct, action is taken such as keying the data into an operatbnal system. 
Generally, no information is returned to the originator He has to wait until his request is satisfied, or he has to get 
infoimattc^i by phone or mail, 

40 The document are to be kept not only during all the time the involved approval prcx;ess is running, but atso after 

that, during a retentbn period fixed for each form. 

Disclosed in the Patent US-A-4, 503,499 is a system wherein a specific user. i.e. a so-called *effort manager' is 
assigned to define a route specification and enter corresponding data into the computer system. White disclosed in 
Patent Abstracts of Japan, Vol. 9, No 206(P/149), of October 19, 1982, is a system wherein the document meant to 

45 receive approval by circulation is inputted together with circulation order facilities. 

All known systems, however, lack efficient means for monitoring fllled-in forms (herein referred to as documents), 
then computmg fully dynamically and electronically the specific and con-ect approval path to be followed by each con- 
sidered form based on Its ccmtents v^en filled-in, with reference to predefined sets of approval rules to be combined 
with varying titles or hierarchical positk>ns of respective users to be automatically selected wi^in the system users 

50 populatbn, and controlling said path as well as filtering any user's request for access to flllednn documents based on 
the requestor's function within the user's organizaibn. 

Summary of the Invention 

5S One object of this invention is to provide a syslem for accessing a prastored blank form library, selecting a form, 

filling- in said form, computing an approval patfi based on filled4n form data and on specific predefined approval rules 
referring to user's job or function within the population of system's attached users, and monitoring and controlling the 
corresponding approval operations. 
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Another object of the invention is to provide a system for fHlering any request for access to any filled-in form 
(document) based cn fllled-in cteta, stored updatable approval rules and requestor's identity 

In other words, this invention ackJresses the automation of all the steps involved in the processing of documents 
whose contents require cc^plex approvals. 
5 That includes documents origination, approver list determmation, electronic signatures (i.e. approval) authentift- 

cation, finahzation operations, storage and general tolbw-up of the p^cess. 

More particularly the invention, as claimed, addresses an approval system for controlling the processing o1 a user 
originated document requiring electronic approval by system selected users, in an electronic mailing system Including 
terminals attached to a digital network, virtual machines (VM) Including computer means, memory and software facilities 
1 0 assigned to individual users, each user being assigned a job or function within the popu lat Ion of system atl^ched use rs , 
and means for generating processing and monitoring electronic documents to be mailed from any terminal to any user, 
said approval system including; 

means for storing and updating function tables wherein each system user's function and address are identified; 

15 

means lor storing document forms; 

means for storing predefined approval rules based cffi user function document type and document forms contents; 

^0 , tenninal controllable means for selecting, accessing, filNng-in, processing and mailing any selected form whose 
contents Is to be subjected to approval; 

means sensitive to said mailing for addressing said function tables and, based upon said approval rules, tor de- 
termining the approval path among the system attached users; and, 

2S 

means sensitive to said approval path determination for monitoring the mailing and processing of said filled-in form 
accordingly. 

These and other objects, characteristics and advantages of the invention will be explained in the following with 
50 reference to the attached drawings^ 

Brief Description of the Drawings 

The figures attached respectively represent: 

35 

Figure 1 : digital network wherein the invention would be implemented. 

Figure 2: portion of a network of Figure 1 . 
40 Figure 3: a basic system architecture for implementing this invention. 

Figure 4; a flow chart for the invention. 

Figure 5: a software architecture for the invention. 

Figure 6: a symbolic representation of the inventbn. 

Figure 7: a mapping of system tables to be used witii the invention. 
50 Figure B: a document structure 

Figure 9: a flow chard for accessing documents processed with the invention. 

Figures 10-13: mesure oriented charts for operating the inventicn. 

ss 

Figures 14-17: detailed flow charts of the invention operation. 
Figure 18: a table to be used with the invention. 
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OQscrjptlon of thQ Preferred Embodiment 

Represented in Figure 1 is a digital network node including both application re^urces and corr^munication re- 
sources. Terminals 11, T2, for instance IBM 327Xor 317X. i.e. inteiHgent displays, are attached to a host computer 
5 (IBM 3090} either directly, or through a concentrator or Canmunlcation Controller (IBM 3725) or a "Private Branch 
Exchange (PBX)' for remote terminals. Several similar nodes are connects into a digital network leading thus to 
thousands of terminals attached to the network. Users sitting at any terminal can both perform selected tasks using 
the network software resources, and communicate with each other at will, day and night, by simple keyboard operations. 

Let's assume the system including the host conputer is operating in a VM/SP environment, Each person, or end 
10 user, is assigned a Virtual Machine (machine) in the cx^mputer system within a given node of the netvrork. N^rtual 
Machine means in fact a predetermined size memofy location sometimes referred to as user's A-disk and means to 
share common computer hardware and software resources, essentially Including the IBM Control Program (CP) and 
Conversational Monitor System (CMS), each including its own types of sen^ices. CP manages system resources and 
provides an individual working envircximent for each persoi using the system. Resources managed by CP include: 
IS Processor functions; processor storage and input/output devices. CP creates the system work environment, it controls 
the system resources that are available to the user during a work session. 

CMS, although a component of VM/SP operating system, is itself an operating system running under CP, As the 
name ^conversationai^ implies, there is a two way communication between the system users and CMS. 

For more detailed information on IBM CP and CMS one may refer to the foHowing IBM documents ; 

20 

- Virtual Machine/System Product (VM/SP) General information. GC20'1838. 

" Virtual Machine/System Product : CMS USER'S Guide, SC19-6210. 

, Virtual Machine/System Product : System Product Editor User's Guide, SC24-5220. 

As illustrated in Figure 2, a user may initiate a session using any of the temiinals attached to the network, and 
througha logon procedure reach his/her machine. Loggingon means sending an interrupt conmand from the keyboard 
to reach CP facilities and then identifying himself (herself) to the system by typing a personal identification code (userid) 

30 and in most cases a password. Password use enables forbidding access to a given ''machine* by anyone but the 
machine "owner". Passwords are secret and known to the sole owner Then CMS resources and/or any other software 
resources (e.g IBM "Professional Office System (PROFS)" application programs) and/or any other specific software, 
such as the one designated here by "SEALING" designed for this invention, may either be accessed on request or be 
accessed directly This is defined in the user's PROFILE EXEC routine tailored to identify the available resources 

55 assigned (i.e. made available) to the specific user upon originally defining the user's machine. For rmre detailed in- 
formatk)n on IBM PROFS one may refer to the following IBM documents: 

- Using the Professional Office System (Order No. SH20-5604) 

^0 In addition, for the purpose of this jnventbn, a specific environment has been taitored within the system as repre- 

sented in Figure 3 showing details of the so called *SEALIMG'' environment. Said environment includes a data base 
machine (SEALDBA) and a system machine (SEALSYST) in addition io user's VM machines. 

SEALDBA is a virtual machine running in disconnected mode as a "Structured Query Language/Data System 
(SQLVDS)" data base administrator machine. Attached to the SEALDBA machine are several mini-disks operating in 

^ a read/write (IR/W) mode : 

an A-disk only used as working disk for maintenance operations; 
a Directory disk containing the data-base directory; 

so 

* a Log-disk which supports iogging of all the work units and albws rollback in case of problem; and, 

- several Data disks : at least one for common system tables, and as many as required by different forms supported 
(document/foim meaning will be defined further). The SEALDBA machine may be considered an SQL machine 
essentially including the data bases in SQL form. 

SEALSYST is the SEALING system virtual machine. Attached to this machine are several mini-disks : 
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an A'diSk only used as working disk lor mair^tenance operaticrts; 

a Batch-disk 1o supfxirl Batcli opefations; 

s - a Source-disk which contains the source ol all the programs; and 

a Syslem-diskwhichccniains a If necessary routines for a user to run the SEALING application, i.e, routines needed 
by the approval application and further defined In this description. When a user wants to run the application, he 
has to make a read-only link to this rnlnidisk. 

10 

The USER'S VIRTUAL MACHINE is a standard VM machine with a memory size of 2 Meg and a user's A-dlsk. A- 
disk is mainly used to store documents drafts and to support print operations. 

Both, the standard user's VM machine and the SEALSYST machine may communicale with the SQiyps data base 
administrator machine via Inter User Communication Vehicle (lUCV Link). 

This system architecture provides several advantages v^ich will be made apparent in the following description. 
Bui, it may already be stated that it contributes to provide a higher security level to the approval process. To that end, 
the only SQL commands the end user may use are predefined into access modules stored Into the SEALDSA machine 
attached disks. The lUCV link enables accessing and running these modules, and cnly these modules, from the user's 
temninal. 

^0 To simplify understanding the detailed descripticn of the preferred embodiment, one may first note the folio wing 

assumptions. Unfilled (blank) forms have been designed and stored in the system (SEALSYST) for further use and 
conversion into documents to be processed (e.g. approved) using the invention. 

Approvers are normally designated by reference to their functicwi. e.g. manager first, second. ... line of department 
No. XX. The function may be delegated, in v^ich case the "acting^ person would be different from the original assignee 
(titular) of the function. 

When the system user (originator of a considered document) wishes to forward the document for proper approval, 
the approval path is dynamically computed using the contents of spec if ic data fields within the document , and predefined 
approval rules. In the following implementation, the approvers may have been split into two categories : "Authorizers" 
and "Reviewers". Only an author izer may accept (concur) or reject a document. A reviewer can only give an advice. 

50 A negative reviewer's opinion requires a subsequent authorizer approval for the document to proceed. 

Finally, after being processed by the last approver, the document Is forwarded autcHnatically to a finalizing VM 
machine performing conventional operations such update, formal and if required encrypt and send through the netwrk 
to another network node, and, for the purpose of this invention, perform a cc^iSrol operation tailored to ascertain a 
higher security level to the approval system. 

35 The above operations are summarized in Figure 4, using the facilities made available through SEALDBA, SEAL- 

SYST as well as the VM user's machine. 

It should be noted therein, that the document as well as any information (e.g. functions) required for approval are 
not forwarded from cme approver to the next. They are accessed from the genera! data base dynamkially. This archi- 
tecture enables updating constantly the approval path to the company's personnel (users) moves or reassignments. 

40 From a functional standpoint the software architecture is organized as represented in Figure 5, In other words, 

access to the approval system is provkied by software tools in "Restructured Extended Executor (RSXX)* language. 
These tools (programs) will access the Nbrary of SEALING General Purpose Programs as well as access a Dialog 
Manager The Dialog Manager In Interactive Structured Programming Facility (ISPF)^ language controls the following 
functions: screen display on any users terminal; tables in memory; and messages generation. The dialog manager 

^5 performs the tasks of a user interlace. For reference on iSPF one may refer to the IBM brochure ISPF Version 2 Diatog 
Management Services SC34-2173. Accesses to said dialog manager are performed by the entry REXX unit and by 
the general purpose program unit. A Data Base Administrator is provided v^ich contains SQL/DS tools to select; 
update; insert or delete data from a DATA BASE stored on disks. Sakd Data Base Administrator is accessed by the 
Genera! Progranrw using SQL orders. For SQL, one may refer to : 

so 

SQUData System General Intormatbn GH24-5064 
SQL/Data System Tenninal User's Guide SH24'H)45 

Represented in Figure 6 is a symbolic representatbn of the approval system centered m an SQUDS data base 
accessible on Read/Write basis throughout the process. An entry for a document preparation (as will be explained 
later) involves read/write operations into the data base. This process step ts folbwed by an approval step which can 
be triggered from both the document preparing user or directly from an approver Once approved the document is 
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further processed, lollowed-up and executed as needed. For that purpose not only the SQL/DS needs be accessed, 
but externa! systems too, like, lor instance VM dlr^tories otherwise avaliabte. The document is finally forwarded to 
storage. Also available are means for updating "function"" data particularly useful to the approval process; and ccxisuit- 
ing/analysis means to be used for instance lor performing statistical operations. 

5 Represented in Figure 7 Js a rnapping of the system data to be stored into the data disks of the SQL oriented data 

base o1 SEALDBA machine. 

System data can be split into general tables required to run the system and specific tables v^lch are accessed 
and/or generated when needed by the approval process. Obviously, the conter^ts of said tables are based on prese- 
lected approval criteria which could be changed and therefore are not limitative. The following description is made with 

10 reference to criteria implemented in the preferred embodiment, 

(A) In General Tables, one can find: 

1. The LOGON tables including users identification data, (e.g. nodeid; userid). 

IS 

2. Tables related to FUNCTIONS ; it is herein assumed that the approval system users are assigned specific 
functbns governing the approval rules (e.g. managerial organization). Said tables include : 

FUNCTION tables defining existing functions and providing lor each function an acting person and a titular 
20 perscxi identification. 

PREVIDEL tables registering previsions of delegaticxis, assuming approval cc^petsnce could be delegated 
from one person to another. 

2S - HISTFUNC keeps track of any modification occurring In function tables for audit purposes (new function, del- 

egatic^, change of titular). 

3. Tables related to APPROVAL prcxess : 

APPFUTU, APPWAIT and APPDONE relate to documents in progress. 

30 

APPFUTU contains for each document the functbns to be involved (in the future) in the approval process. 

APPWAIT contains lor each document the functions awaiting for an action on the document. 

3S - APPDONE contains for each document the functions having already acted on the cbcument, the d^!sk>ns 

and idenlilicalion of the parson(s) who acted and the titular if different. 

APPHIST deals with documents which are no more in progress, i.e, they have been finaNzed, rejected or cancelled, 
IX has exactly the same structure as APPDONE. 

40 

4. Tables related to DOCUMENTS : 

F il ied-in forms provide so cal led documents to be s ubjected to the approval process. Each document includes 
at least a HEADER with the data defining the document. All headers are dynamically stored into HEADERS tables. 
COMMENTS Tables contain for each document the comments added by the approvers during the approval prcKjess 
^ as they act on the document. 

(B) In the specific Tables, one can find : 

1 . Tables dealing with FUNCTIONS : 

50 

determination of function table coded FafuncDn; 
characteristic of function table coded F^funcCn. 

(tunc is a code tor type of function and n in Cn and On is an integer sequence number). 

55 

2- Tables on DOCUMENTS : 

Typdocan represents lor a given lorm (or type ol document/typdoc) a set of n tables needed to contain the 
specific document data. 
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Control tables are sometimes necessary to control the data entered to prepare a document or to mcKlify these 
data during approval process. Once defined and updated, they can be used lor several different types of dccu- 
ments. 

Follow-up tabies are sometimes necessary to give loHow-up information on definitely ^proved documents, 
* An example of Function Table is represented hereunder : 
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Function 
Type Reference 
(Typfun)CReffun) 


Acting 
Userid Node 


Titular 
Userid Node 


Last 
update 


Delegation 
Index 




1 


IMDI 


079954 


MARTINS 


I40EVM2 


MARTINS 


LGEVM2 


860513 




15 


2 


imi 


071328 


DAVIS 


LGEVM2 


DAVIES 


UJEVM2 


880622 






3 


IKDI 


055413 


HACKERS 


LGEVM2 


HACKERS 


LGSVM2 


881130 






4 


MAHA 


0793 


MARTINS 


LGEVM2 


MARTINS 


LGEVM2 


880524 




50 


5 


MANA 


0830 


MARTINS 


LGEVM2 


DAVIES 


LGEVM2 


880515 


D 




6 


ISFC 




JONHSON 


LGEVM2 


DAVIES 


LGEVM2 


880318 


D 




7 


PUHC 


45 


HACKERS 


LGEVM2 


HACKERS 


LGEVM2 


880513 




25 


8 


IHDI 


022007 






ROOVSR 


tGEVM2 


8809X3 






9 


MANA 


0750 






ROOVER 


LGKVM2 


881213 




30 


10 


MAHA 


1000 


ANDERSON 


LGEVM2 


SCHMIDT 


DCTVMI 


881024 


S 


11 


INDt 


045345 


ANDERSON 


LGEVM2 


ANDERSON 


LGEVM2 


881012 






12 


INDI 


087632 


JONHSON 


LGEVM2 


JOHNSON 


LGEVM2 


88X103 





35 



An important concept of the system is the concept of 1unctlon^ in a cwnpany or any group of people wfthin which 
the approval system is needed to operate, prerogatives, e.g. approval competence, are assigned based on pb assign- 
ments or title, herein referred to as *'Functio^^ 

In an approval process, it is not tie signature of a specific perscMi which is required, but the signature of the person 
presently assigned the required function, 

A function can be defined as a sum of prerogatives acknowledged by the company and assigned to a person. 
Conversely, a given person may have several different functions. 

The approval system of this invention consolers functions assigned rather than pec^le. There are a lot of advan- 
tages to use this critenum because functions are generally more stable that people. For instance, approval rules defined 
in a company are generally related to people's level within the company (hierarchy). 

in the system, a "function" is completely defined by : 

" a type of function (Typfun); herein coded with four characters 

so 

Manager (MANA) 
Budget Gc^troller 
Financial Analyst 
- Purchaser (PURC) 



g^J'^^'ltg^^PtPt^^r'^^'^ (Reffun): coded with six characters 
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Managed department number for Managers 
- Code for Financial Analyst 
Code for Purchaser 



When atynctbn is unique, reference is not neceseafy. For oxampie, the function "Plans & Controls^ is unique. 
The function "employee^ Is a basic function meaning being one of the company*s employees. Its reference can be 
the serial number assigned to the individual at hinng. 

The type of function has been codified with 4 characters : 

10 

INDt is for "Employee" 
MANA is for "Manager" 

- PURC is for "Purchaser" 

- CTLG is for "Controller** 

r5 - ISPC is for 'Plans and Controls'* 

□send and nodeid identify a VM machine and consequently a unique person. 

"TITULAR" designates the owner, i.e. the person who is assigned the function while "ACTING" is used to designate 
the person actually doing the job presently 
^0 For instance MARTINS is the employee whose reference number (Reffun) is 079954 (line 1 ). He is also manager 

of the department number 0793 (line 4). He is acting as manager of department 0830 by delegation o* DANCES (line 
5) who is employee number 071328 (line 2). 

HACKERS is employee number 055413 (line 3) and a!so Purchaser code 45 (line 7). 

DAVIES has delegated his tunctta of manager to another manager, MARTINS, as seen before, but he has dele- 
^5 gated his function of Plans and Controls to JOHNSON who is not manager (line 6). 
BOOVER {line 8 and 9) is absent (and nobody is acting for him). 

SCHMIDT is not on the same node and has no electronic signature system, so ANDERSON is in charge of entering 
his decision in the system. He acts as "substitute" for SCHMIDT (delegation index Is S). 

Some functions are already managed in specialized systems attached to the network. In that case, a link to the 
30 specialized system will enable getting rid of the hassle of the Function Table maintenance. For instance in a Company, 
a Perscfinet Department System provides indications of titular for the following functions: 

employee (referenced by his employee Serial number) 
department manager (referenced by nnanaged department number) 

35 

The system provides an interactive means to manage any other function, as soon as this function becomes nec- 
essary in an approval process. 

Examples of APPROVAL TABLES oi Figure 4 are represented hereunder. 

40 APPROVAL TABLES 



Document 


Function 


App. 


Mand 


Order 


Type 


Refer. 


Type 




type 


tory 




( Typdoc ) { Re f doc ) 


(Typfun) (Reffun) 


(AppTyp) 


(MCS) 




DAFONC 


0JA54 


MANA 


0798 


A 


M 


1 


DAFONC 


0JA54 


MANA 


0792 


A 


M 


2 


DAFONC 


0JA54 


CTLG 


LGE 


A 


M 


3 


DAFONC 


0JA54 


PURC 


45 


R 


M 


4 


DAFONC 


0JAS4 


PURC 


74 


R 


M 


4 



8 



EP 0 387 ^2 81 



Document 
Type Refer* 
(Typdoc) (Refdoc) 


Function 
Type Refer, 
(Typfun) (Reffun) 


App* 
type 


Mand 
tory 


Previous 
approver name 




DAFONC 0JA54 


MANA 0793 


A 


M 


Johson, Alex 











Comments for previous 


In wait since 




approver 


Date Time 




OK for me 


881023 153407 



Document 
Type Refer. 


Function 
Type Refer, 


App. 
type 


Mand 
tory 


Deci 
sion 


Acting 

Emp N** Name 


DAFONC 0JA54 


MANA 0732 


A 

* 


M 


Y 


079954 


Schmidt, John 











Titular 

Emp N° Name 


Deleg 
Index 


Action on 
Date Time 


071328 


Davies, Philip 


D 


861023 153207 









APPHIST : same structure as APPOONE. 

APPFUTU : contains lor each document in the approval process the lisl of lunctions which will have to deal with 
the document later on. 

In this table the document is uniquely identified by the type of document (typc^), v^lch is In fad the cede for the 
form from which the dcx^ument is derived and a reference (reldoc) within this type, in this appiication, one shouki 
remember that the expression ''document^ should normally mean a filled-in form, and that several prestored forms will 
be available. 

The function is identified as mentiCMied previously in FUNCTI ON table by a type of function (Typf un) and a reference 
number (e.g. Service or Department number (Reff un)). An order number 1.2,3... indicates which lunction(s) will need 
to approve next, assuming no changes to the approver list has occurred. Several functions can have the same order 
number. 

Approver type (Apptyp) indicates if the function is in the list as an Author izer (A) or as a Reviewer (R). The Authorizer 
actions coufd be "Authorize" or "Reject"; while a reviewer should "Approve" or 'OisapproveV 

An index indicates it the functicwn is mandatory or not on the approver list. This will be important to n^ke changes 
in the approver list, if the f uncticxi is not mandatory, any approver can suppress it, but il it is mandatory, either it Is not 
possible to suppress it, or another function must replace it. 

APPWAIT contains tor each dccument in approval process fie function(s) vM\ch are actually waiting for the doc- 
ument (i.e. next to act). 

As APPFUTU, it contains document identification, function Identification, approver type and mandatory indicator 
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It contains also the previous approver's name, one line personal connnnents from the previous approver, the date and 
time of previous actbn. 

APPDONE : contains lor each document the functions that have already acted on the document, the decisions 
and identification of the persons who have acted and of the titular if he is different, 

As APPFUTU and APPWAIT, it contains document identificatiw, function tdenttfication, approver type and man- 
datory Indicator It contains also the decision of the approver V for Authorize or Approve; N for Reject or Disapprove, 
the identificatlcn of the approver, name and employee serial number, the identification of the titular of the function, 
name and employee number, the delegation Indicator, the action date and time. 

As already mentioned, the approval system for the best mode of this invention is made to use predesigned forms. 
Any user wishing to start a request for approval c^eration, will access a document form (b^ank)and fiH-it in. A form 
includes predefined fields which, when fllled-in m\\ be stored into a set of tables including, among others, a table 
''HEADERS"- 



Docviment 
Type Refer. 


Sta 

tU8 


Flag 


Originator 
Type Refer. 


Kmp no Name 




DAFONC 0JA54 


P 


N 


INDI 0799S4 


079954 


Schmidt, John 





















Subject of the document 


Created on 
Date Time 




Bub transportation for kick-off meeting 


881023 153407 







This table cCMitatns header data required for any document. 

The key of this ^ble is the dccument identification, i.e. type and reference of document. Each document is assigned 
a status (c^e character) which can be : 

P : document is in progress in approval process 

F ; document is finalized, approval process is over. 

S : document has been sent to an operational system 

T : document has been transmitted for action (acknowledgment received from operational system). 

H : action involved is terminated 

R : document has been rejected by an Authorizer 

C : document has been cancelled by !he Originator 

A flag is used (o indicate that the correspcwiding document is currently being processed by someone. It the flag is 
set to Y (yes), the system bars someone e!se*s access to the document. 

The Originator is k:ientified In HEADERS table by his function (e.g. IND! for employee), his employee serial number 
and his name. 

The table also contains the subject of the request submitted to approval (document) and the originating date and 
time. 

In addition to the function tables already mentioned system will use Specific Function Tables storing data to 
be used for defining the approval rules selected by the form user^s company. 
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DETERMINATION TABLE: (D) = FafuncDn wherein "func" is used 
to designate function type. 



Key 



gives: 



Parameter 



Reference of function 



Exainple: FaMANADl 



Project Number 


Responsible department 
(reference for F\inction 
Manager) 


4577310 
4012306 


0793 
0755 



CARACTERISTIC TABLE: (C) = FafuncCn 
Key gives: 



Reference of function 



Parameter (s) 



Example : FaMANACl 



Department of manager 


Expense authorizations 
Personal General Investment 


Laet update 


0793 
0755 


10000 20000 15000 
25000 50000 35000 


881022 
871231 



These tables allow retrieving a function reference trom a parameter. They wHt be used during approver list deter- 
mination. 

The example shows so called Determination Tables useful to detemiine the manager who is responsible lor a 
ckxumenled project 

Function CHARACTERISTIC tables enable determining parameters from the reference of a gtven type of function. 
They will be used during approver signature validation. In other words, these tables store predefined approval rules, 
The example shows the amount of expenses authorized based on the considered manager's funclbn and the 
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company's eetected rules selting expense thresholds, 

From the above considerations, one may understand that any fiOed-in form (-document) contents is dyn^icaliy 

used by the system to determine the approval path when considered in combination with approval rules. In addition, 

the system is designed to enable adding or modify hg forms, as needed, in a fairly simple way Therefore, the various 
5 types of information fields ccxitents should be organized to enable convenient processing of said fields. To that end, 

each field contents for all fi!led-in forms is stored in a document table, and these various tables are made to be related 

to each other according to a predefined tree structure (see Figure 8). 

!l the form is simple, its data can be contained In one single table typdcx;^! for the dcx^ument (TOP) data table (NB: 

"typdoc" is used to designate document type and corresponding form code). 
^0 If the form is nrrore complex, tables typdoc^S, typdoc^3, typdoc^n can be defined to contain data which are 

dependent and have a variable number of occurrences. These tables will be related to each other according to the 

mentioned tree structure. 

To illustrate the above, a specific example (Genera! Expenses Purchase Request) Is shown hereunder. 
IS Table 1 



Header of Purchase Request 


Kevs : 






KEYI 


CHAR(5) 


Reference of request 


Non-key variables : 






PROFi 
MAUTO 


CHAR(7) 
DEC(11,0) 


Project to be charged 
Maximum amount 



Tabie 2 



Items inside Purchase Request 


Keys : 






KEYI 
KEY2 


CHAR(5) 
SMALLINT 


Reference of Request 
Item number 


Non-kev variables : 






QTDEM 
FPUHT 
DESC 


DEC(7) 

DEC(9.2) 

CHAR(30) 


Requested quantity 
Estimated unit price 
Item main description 



Table 3 



Complementary description of an item 


Keys : 






KEY1 


CHAR(5) 


Reference of Request 


KEY2 


SMALLINT 


Item number 


KEY3 


SMALLINT 


Line number 


Non-key variables : 






DESCC 


CHAR(30) 


Complementary description line 



Having defined tiie system organization, one may now understand the principles used for any user's access to a 
document (see the flow chart o1 Figure 9). 

First, the user is recognized for being logged on a virtual machine v^lch the system knows as a ^signature^ (ap- 
proval) machine assigned to a registered user. 

The FUNCTION table is the main filter to access the documents. Said table is permanently updated to reject the 
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actual f unctioi o1 all users attached to the network. Once authorized access by ttie filter, the table to be used by the 
system depends on what the user wants to do : 

APPWAIT is used to determine the documents awaiting the actbn. 

5 

HEADERS is used to find documents origins. 

APPDONE or APPHIST are used to find documents on which action has been taken already. Dcx;uments partially 
approved are stored in table APPDONE. while those approved by all required approvers {or rejected) are stored in an 
10 APPHiST or historic table. 

To make the system attractive and end-user friendly from an operational stand^int, panels have been set and 
functional keys (PF keys) assigned specific tasks. 

The system does not assume any level of technical knowledge or expertise. It does assume however that the user 
is sonehow familiar with document processing tools presently available; e.g. IBM PROFS or a similar Office System. 
15 More generally speaking the system is menu driven as wH! be shown hereunder on implemented examples. 

First, the system is accessible by typing a CMS command through the user's terminal (e.g. typing 'SEALING"), 
which links the user^s VM machine to the SEALSYST VM system-disk. Assuming the IBM PROFS system is available, 
then a PF key would have been customized for direct access to the system, in both instances, the system would load 
programs (EXECS or routines) for preparing. prcK^essing or consulting, etc... documents, and presenting the folbwing 
20 menu on the user's dispiay. 



SEALING MAIN HENU — 

Press one of the following PF keys 
PFl Prepare a document 

PF2 Process documents awaiting your action 

PF3 Consult documents you have originated or acted upon 

PF5 Look at docxinients awaiting someone else's action 

PF7 Delegate or retrieve your authority 

PF8 Transfer or retrieve your VM Userid and Password, 

PF9 Help PF12 Return 



The user may select one of the options by depressing the PF key associated with said option, For example, to 
50 Prepare a Dc«;ument, the user should press PF1 . 

He can also press PF9 to get a HeJp screen and that is the case for all the panels displayed in the system. PF12 
enables quitting the system. 

if the user presses an unused PF key, for instance PF4, an error message is displayed at the bottom of the screen, 
just above the PF keys description line. 
S5 Obviously the first operation a user needs perfomiing is selecting a prestored form and filling said form in, to 

prepare a fifled-in form, i.e. a document. 

Depressing PF1 on menu 1 calls PREPARE EXEC. (See Fig. 10 for a high level flow chart of the process for 
preparing a document to be submitted to approval). 
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This EXEC starts displaying the list of forms available to the user in a "Choose a Form Category" menu. It shouSd 
be noted that the system is made to process forms of various categories iike "purchasing" orders (APPR), "financial" 
orders (FINA), requests for getting approval to tailor a VM Machine to a new user (LOGO), etc... 



Choose a Form Category 



Press the PF Key for the Form Category you want to Choose. 

PFl Purchasing forms APPR 

PF2 Logon request forms LOGO 

PF3 Financial forms FIHA 



PF9 Help FFIO Next FFll Previous PF12 End 



If there are ttx) many categories to fit on one screen, the user can scroll up and down using PF10 and PF11 
respectively through the list to find the right category. Once a category is selected, a list of available forms within the 
category is displayed. 

For example, if "Purchasing Form" has been chosen, the following ^Choose a Form" menu is displayed. 







Press the PF key for the Form you want to choose* 




PFl Basic Purchasing Request 

PF2 Request for Price and Delay Quotation 


DAFDNC 
DEKPED 


PF4 Request Order 


BORDRE 


PF9 Help PFXO Next PFll Previous PFX2 


Return 



The user may select the form which fits his present need. Help screens can be displayed at user's request and 
explain in which circumstances each form must be used. 

Suppose the user presses PF1 on this menu. The menu below is then shown (assuming the requestor is the 
function owner and therefore his function has been allowed access to this kind of form). 
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10 



15 



20 



2B 



35 



Prepare Main Menu 



Form title : Basic Purchasing Request 



Press one of the following PF keys. 



PFl Prepare a document using a blank form 
PF2 Change a Draft 

PF3 Prepare a document using an existing Docuffient 

Type the_reference of the existing document, then 
press FF3 key 



PF9 Help PF12 Return 



The user may select cme out of three methods to prepare a document: 

PFl Prepare a ckxument using a blank form. A predesigned form v^k:h includes input zones containing blank 
fields to be fiiled-in or already fillad-ir^ by "defauft" data which could be amended by the user at will. 

PF2 Change a Draft. The user is shown a list of drafts of that form he has prevk^usly filled4n or just begun to fill- 
in and stored without sending as a document. 

PF3 Prepare a document using an existing Document : the user has to type the reference of a document he is 
allowed to access and !he system builds a new draft copying the data of this document. The system checks in this 
case that the reference exists in the data-base and that the user is either the originator, or oriB of the approvers. 
Thus filtering access to said existing document. 



The layout of the screens which the user is presented with, depends on the original form designer's chobes. 
For example, if the form "General Expenses Purchase Request" has been chosen the screen below Is sho\An. 



4S 



so 



55 
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1$ 



so 



30 



35 



40 



45 



SO 



55 



General Expenses Purchase Request (Header) 



Subject : Transport by bus 

Addressee : DUPOHT Department: 0693 

Confidential Information : N (Y/N) PC parts or softwares : N (Y/N) 

New chemical product ; N (Y/N) 



Project to be charged 
Haxiwiura amount (FF) 
Expiration date (JJMMAA) 



582310 

lOOO Total ; 1000 
. , , . . (optional) 



Cmd = X (Select), D (Delete), A (Add) ,R (Repeat) PF8 Next PF7 Previous 



Gmd Item Description 



Quantity Unit price Delivery 

week 



transport by bus 40 places 
Vence-La Gaude on xx/xx/xx 



1000 



22 / 88 



PFl Search PF5 Submit PF9 Help PFIO Next PF12 File 



The user can B\-\n here the *head8^^part of the form. 

AW fomns have a SUBJECT field. The "SEALING* system of this invention will use this field v\^en showing the 
document on a list of dcxiuments. For instance when showing the list of documents awaiting someone's action. 
Scxne data have already been fiHed-in (default) and can be modified : 

- The addressee (originator) and his department 

The flag "Confidential Infom^ation'* indicates that confidentiai information are to be given to the supplier. 

The flag *PC parts or softwares^ indicates if the request contains such parts. 

The flag "New chemical product^ indicates if the request contains a new chemicai product. 

Some data are mandatory; like for instance the subject, and the project to be charged. 

Some data are retrievable by the system for user's convenience. That might help for instance by enabling consu Iting 
the list of projects ran by the company's department the involved system user belongs to. Therefore, search is available 
for the project "field". 

If the user sets the cursor on this filed and presses PFl , he will be asked for a department number and the system 
will display the list of projects for that department. The user can choose one of these and the field of the request will 
be automatically fitled-in with the chosen project. 

When the header is fiHed-in, the user has to tili the remaining items. He can press PF10 to get the item paneL 
When one or more items are entered, he will be abie to select one item by typing X in front of it; or to repeat, delete or 
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add a new item by typing D or A. 

Depressing the ENTER key or any PF key, triggers a trivial data ciiecktrtg. If any checking lails. the required action 
is not performed, an error message is displayed, the cursor is positioned in the field in which error was detected and 
the field Is highlighted in reverse video. 

With the second screen (display upon depressing PF10), the user fi!ls-in all the data for a particular item of the 
Purchase Request. 



General Expenses Purchase Request (Item) 



Subject : Transport by Bus 



Haximum fimaount (IF) 
Project to be charged 
Item number 

Price request reference 
Purchaser code 
Part number 
Quantity 

Delivery week (WWYY) 
Unit price (FF) 
Item project 



10000 
4S77310 

1 PF3 Repeat item PF4 Add an item 



Deliv. delay 

99 Purchaser name 

EC level 

1 Measurement unit 

22 / 88 

1000 (optional) 

(if different from header) 



weeks 
Billiard, Jean 



Cmd= D (Delete), A (Add), R (Repeat) 



PFa Next PF7 Previous 



Item description 



: Transport by bus 40 places 
Vence-La Gaude du xx/xx/xx 




Some data are mandatory : e.g. : Purchaser code; Delivery week; Quantity; At least CMie line of description or a 
part number. 

Some date are optional : e.g. : Price request reference; Part number; Item unit price; Measurement unit; EC (En- 
gineering Change) level; Item project has to be fiiled only if it differs from header; and Complementary description Hnes. 

Search procedures are available from this screen by putting the cursor in the selected field and pressing PF1 ; for 
price request reference; Purchaser cc^je; part number; delivery week; or project. 

The user can type several lines of complementary description for the item . A command area allows adding repeating 
or deleting lines. Scrolling is possible through PF7 and PF8. 

Other PF keys are used : 



PF2 Go to the header screen 
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PF3 Repeat the displayed item to create a new one 
PF4 Add a blank item 

PFS All operations before sending in approval (see below) 

PF10 Display next item if it exists 

PF11 Display previous item if it exists 

If the user presses PF12, the system shows the screen beiow. 

_ ~ 

^^^^^ Process The Dociiment 

Document : General Expenses Purchase Request 
Reference: 

Subject : Transport by bus 

Press one of the following FF keys. 

PFl View the Document 
PF2 Change the Document 

PF4 Add comments 

PFS Review Approver List and Submit the Document for Approval 
PF6 File the Draft in your Personal Storage for further changes 

PFS Print the Document 

To erase the Draft, type DELETE below and Press ENTER 



PF9 Help 

From here, the user will be able to : 

PFl : View the document as ft can be viewed later by all the approvers 
PF2 : Change the document data 

PF4 : Add free comments which will be viewed to all Ihe approvers 
PFS : Prepare sending in approval (see beiow) 
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PF6 : Save the data entered as a draft document (and retrieve ti later) 

PF8 : Print the document. A print image o1 the dcx^ument is then added in a fWe calted 'print file". The user will be 
able to print this file at the end of the session 

type "DELETE" in the provided field to erase the in process draft 

Some of the above defined PF keys functions are self explanatory. Others need some explanations. For instance, 
by depressing the key PF4, the user gets the following items on his screen : 



^jj^j Personal Comments 

Type ; General Expenses Purchase Request 

Reference : Draft 

Subject : Transport by Bus 

Comments : 
* * * Top of File * * * 



TFZ Add line PF3 Retuirn PF6 Erase line PFIO Forward FFll Backward PFi2 File 



Input -mode 

1 File 



The user can type free cOTiments and use PF keys as described hereafter : 
PF2 to add a blank line below cursor position 
PF3 to leave without saving last modifications 
PF8 to delete tlie line where the cursor Is 

PF1 0 and PF11 to scroll forward and backward through the comments file 
PF12 to save and leave ccMnments entry 

The above operations are summarized in the self explanatory flow-chart of Figure 10. 

Down to this point the process lead to a fully prepared document ready for being submitted to the approval process. 
Therefore, if the user presses PF5 either from the data entry panels, or from the "Process prepared dtxument", the 
system performs the Jollowing operations. 

First, it checks all the document data (comptete checking). If an error Is found, the system displays again the data 
entry panel where the field bearing an erroneous data is indicated by the cursor Then, it determines the approval path 
based on functions involved, specific rules assigned for the type of document involved, and document data (see Figure 
14). 

If an error is found, the message "Unable to determine approval process"" is displayed and noactii^ is perfomied. 
Finally, it determines for each function of the approval process, the acting person at the present time and the titular 
The result is displayed (see Figure 15) to the considered user (originator) as shown hereunder for review 
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Review Approver List And Subinit For Approval 

Document : General Expenses Purchase Request 

Subject : Bus transport 

PFl Change Approver List 

FF7 Subinit the Docuiueat for Approval 

Function description Name Approver Type 

Manager 0793 Martins, John Author izer 

Purchaser 45 Hacklers , Jimmy Reviewer 



Approval process has been determined 

PF9 Help PFIO Next PFli Previous PF12 Return 



If the user presses PF12, he just returns lo "Process the document*' Menu. 

Otherwise, by depressing PF1 he will be able lo change the approver list with seme controls and restrictions (see 
below with reference to Figures 1S and 16). 

If he does press PF7, the document is created and watts for action oi the first lunctior^(s) in the approval process 
(see Figures 15 and 16), 

Represented in Figure 11 Is a flow-chart summarizing the operations achievable on an already fitled-in document. 
The user can acton documents awaiting his action by pressing PF2 in SEALING Main Menu or directly typing SEALING 
ACT_ON as a command. 

When SEALING has been linked with ISM PROFS application, the user gets a message when depressing the 
functional key labeled "Open the Mair, assuming SEALING documents are waiting action. The message looks like: 

"You have 5 documents awaiting your action in Electronic Approval System. Do you wish to process these ? Type 
Y and press ENTER if you wish". The system then shows first a list of categories of documents as shown below. 
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— List of Documents 

Press the PF Key for the Category of Document you want to process* 

Title Number of documents 

PFl Price and delay Request 2 
PF2 General Expenses Purchase Request 8 

PF9 Help PFIO Next PFll Previous PFi2 Return 

As represented in flow chart of Figu re 1 1 the user has to select a category by pressing the appropriate PF key. W 
When the user has selected a category, the system displays the list of documents In the selected category. If there 
only one category of documents, the first screen Is by-passed. 
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List of Documents awaiting your action 




Farm title : General Expenses 


Purchase Request 




Press the FF Key for the document you want to proces 


5 , 


-^-From- — Date 


Reference Required Action 


PFl Dupont, 


Philippe 880322 


JA022 


Review 




Transport by Bus 






FF2 Beraud, 


Serge 880314 


JA021 


Review 




Safety Glasses 






PF3 Dupont , 


Philippe 680210 


JA015 


Review 




Tables for the Restaurant 




PF4 Dupont , 


Philippe 880210 


JA012 


Infono 




Printing Cards 






FF9 Help 


PFIO Next FFll 


Previous PF12 


Return 



The documents list is sorted by data of required action, the more recent are at the top of the list. Eventually scroHing 
additional screens may be needed. The user can scroll up and down using PFIO and PF11 respectively. 

Then selecting one document is achieved by pressing Ihe corresponding PF Key (PF1 to PF8) which displays the 
ioliowing screen, 
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Process a Document awaiting your Action 

Document ; General Expenses Purchase Request Number JA022 
Originator : Dupont, Philippe 0793 
Subject : Transport by Bus 

Your Function is : Manager 0793 

Press one of the following PF Keys, 

PFl View Tlie Document 

PF4 Add Coraments 

PF5 Add or Modify Data 

PF7 Act on the Document 
PF8 Print the Document 

Previous Approver was : Schmidt, Jimmy 

Personnal Comment from previous Approver : 
OK for me. 



PF9 Kelp PF 12 Return 



The user can see on this screen the document type and reference, the subject, the originator*s name, who was 
the I last previous approver and personal comments from this previous approver. Also mentioned is the lunclton the 
present user is asked to act for, and eventually the o\^er for the lunctbn if the user is a delegate. 

By depressing PF1, the user can view al! information about the dcx;ument, Le. the document itself; the approver 
list with decisions of approvers who have already acted on the dcxjument; the document originator and approvers 
comments, If any. 

Depressing PF4, enables the user adding his own comments to the other approver's ccmments after acting on 
the document. 

PF5 is not available for all approvers. This PF Key is c^ity active if the document is originaliy tailored to authorize 
the function to add or modify data. In tiis case, the user is shown data modification panels and can add or modify data 
in the document. These mcdiflcations can affect the approval path process. 

PF7 must be used to act on the document. 

it the user is an Authorizer, he will see the screen below. 
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j^et on the Docuraent -------^ 

Document : General Expenses Purchase Request JA022 

Originator : Anderson, Philip 0793 

Subject : Transport by Bu3 

Funct ion : Manage r 0792 

Press one of the following PF keys. 

Authorize 
Reject 

Request for Additional Information without taking a Decission 
PF7 Change the Approver List 

PF9 Help PF12 Return 



The user can change the approvers list by pressing PF7 (seen later). 

The user can Authorize (Approve) the dccument With PF1 . The system wH! display a confirmation panel which 
looks as follows. 
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Confirm your Authorization 



Document : General Expenses Purchase Request JA022 

Originator ; Anderson, Philip 0793 

Subject : Transport by Bus 

Function i Manager 0792 

Press ENTER to confirm your approbation. 

Warning : After confirmation you will not be able to change your 
dec is ion . 

You can enter a Personal Comasent: 



For the next approver(s): 



Manager 0792 Schmidt, John 

Delegate of Anderson, David 



FF9 Help PF12 Return 



The next screen shows the next approver and allows the user to type one Nne of personal comments tor said next 
approver's attention, 

If the user is the last approver, the confimnatlon panel is different and boks as fohows : 
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Confirm your authorization 



Document 



Originator 
Subject 



Function 



General Expenses Purchase Request JA022 
Anderson, Philip 0793 
Transport by Bus 
Manager 0792 



You are the last approver* This document will be finalized. 
Press ENTER to confirm your approbation. 

PF9 Help PF12 Return 

AuthDflzation means finalization of the ciocument. 

An Authorizer can also Reject the document. The system will display a confirmation panel which kx>ks as foHows. 
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Confirm your reject 



Document : General Expenses Purchase Request JA022 

Originator : Anderacn, Philip 0793 

Subject ; Transport by Bus 

Function ; Manager 0792 

Press ENTER to Confirm your Reject, 

Warning : After confirmation you will not be able to change your 
decision. 



You can type below a Personal COmment for approvers and originator 
HYREMK 

Information will be sent to approvers who have already viewed 
this document 



Manager 



0793 



Martins, John 



FF9 Help PF12 Return 



The system asks the user to confirm his decision, indicating that In case of non confirmation, the document wifl be 
rej^ted. an informalfon will be sent to the originator and to each approver who has already acted on the document, 
The user may also choose PF3 to request additional inlormation from another approver. 
\n this case, the user has to choose an approver In the screen beiow, 
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- Request for Additional In format ion - 

Document ; General Expenses Purchase Request JA022 

Originator : Anderson, Philip 0793 

Subject ; Transport by Bus 

Function : Manager 0792 

To request for additional information, choose an approver and 
type an X next to your choice below. 

When you have made your choice on this screen, press ENTER, 



Funct ion Descr ipt ion Nsm 



- Originator 079954 Jacobson, Steve 
" Manager 0792 Martin, John 

- Purchaser 45 Tucson, Joe 

PF9 Help PFIO Next PFll Previous PF12 Return 



He can choose the onginator, an approver who has already acted on the document or an approver who has 
yet seen the document, then he gets a ccKifjrmation pane! as below. 
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Coxifirin your requefst: jior additicnal inforination ----- 

Document : General Expenses Purchase Request JA022 

Originator : Anderson, Philip 0793 

Subject ; Transport by bus 

Function : Manager 0792 

Press ENTER to Confirm your Choice, and the Document will be sent 
to the Manager 0793 Schmidt, John 

FF9 Help PF12 Return 



If the user confirms, the document is avatlabie for the chosen approver and the user will get it back again after this 
approver has acted upon said document. If the user is a Reviewer in the approval process, he is shown the following 
screen. 



^ ***w ^ct on the Document 

Document : General Expenses Purchase Request JA022 

Originator : Anderson, Philip 0793 

Subject : Transport by bus 

Function : Manager 0792 

Press one of the following PF keys. 

PFl Approve 

PF2 Disapprove 

PF3 Request for Additional Information without taking a Decision 

PF7 Change the Approver List 

PF9 Help PFl 2 Return 



There wlH be two different confirmation panels no matter whether the user is the last approver or not. Request lor 
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addftiona! information opGralbn is quite the same as requested to an Authorlzer It should be remembered that a 
Reviewer cannot reject a document. He can just disapprove the document, In which case a further Authorizer approvai 
is required. The system determines if there is an authorizer in the list of next approvers, if there is no Authorizer in the 
jist of next approvers, the system asks the user to choose among the Authorizers who have already acted on the 
document and will send the document back to the chosen Authorizer who will have to conf imn his previous authorization 
or to reject the document. 

If the document has been received tor information only, the user is shown the following screen. 



Document received for Information only 



Document 
Originator 
Sub j ect 



Genera Expense Purchase Request 
Anderson, Philip 0793 
Transport by Bus 



Number : J AO 22 



Your Function Is : Manager 



0792 



Press one of the £o Hewing PF Keys. 



BO 



55 



PFl View the Document 

PF4 Erase the Document from your Incoming mail and keep In your 
mall log 

PF5 Modify and Send again for approval 
PF8 Print the Document 
Previous Approver was ; Durand, Andre 



Personnal Comment from previous Approver 



FF9 Help PF12 Return 



The user can receive such information in several instances. He may be the originator and the document has been 
a a a accepted. Action Is therefore currently in process for execution. Or document has been rejected by an Au- 
thorizer or has been cancelled by the originator and the user is either the Originator or an Approver who has already 
acted on It. 

PF4 has just the effect to cancel reference reminder to said documents. The user can always access the document 
using consuKatbn facilities. 

PF5 is available cn this screen only If the document was rejected. It enables the originator retrieving all the doc- 
ument data, correct something, and send again very qurckly (with a new reference) If he wants. 

Obviously, any user should be able to consuft documents he has originated or acted upon, by pressing PF3 in the 
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Main Menu or directty typing SEALING CONSULT as a command. 
The menu below is then shown to the user 



Consult Documents you have originated or acted upon 

Press one o£ the following PF Keys* 

PFl List Documents in approval process you have originated 
PF2 List Documents in approval process you have acted upon 
PF3 List Documents you have originated between 880301 and 880314 
PF4 List Documents you have acted upon between 880301 and 880314 
PF5 List Documents with search information specific to a form 

PF9 Help PF12 Return 



The user can access documents using several aSernatives {see Figure 12): 

PF1 ; Lets the user access the documents he has originated and which are currently in the approvai process. 
NB: by user one means the person assigned corresponding functbn. 

PF2 : Lets the user access the documents he has processed and which are currently in the approval process. 

PF3 ; Lets the user access all the documents, v^atever their status (in progress, finalized, rejected, cancelled,..) 
he has originated between two dates the user can modify, 

PF4 : Lets the user access al! the documents (whatever be their status), he has acted upon between two dates 
the user can modify 

PF5 : Lets the user access ck?ciiments issued wdth criteria specrfic to a form. 

Whatever the PF key chosen, the result wili be either the message "no document found", or a list ot documents 
found as shown hereafter: 

if the user chooses PFl to PF4, a list of found form categories Is displayed whenever more than one category has 
been used, othervvNse the "List of Documents Found^ is displayed. 
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Type : General Expenses Purchase Request 






Press the PF Key for the Document you want to consult. 






Subject 


Number 


Status 


PFl 


Transport by Bus 


JA022 




In Progress 




You have acted as: 


IBM employee 


0799S4 


on 880314 


PF2 


Flowers buy 


JA021 




In Progress 




You have acted as; 


IBM employee 


079954 


on 880312 


FF3 


Car maintenance 


JA020 




t Inalxzea 




You have acted as: 


Manager 


0793 


on 880312 


PF4 


Protection glasses 


JA019 




Rejected 




You have acted as: 


IBM employee 


079954 


on 680312 


FF5 


Repaint 


JA018 




Final ized 




You have acted as: 


Controller 




on 680312 


PF6 


Garden maintenance 


JA014 




Execut ing 




You have acted as: 


IBM employee 


079954 


on 880305 


PF7 


Request for Writing Assistant JA012 




Rejected 




You have acted aa: 


IBM employee 


079954 


on 880304 


PF8 


Electronic components 


J AO 11 




Executed 




You have acted as: 


IBM employee 


079954 


on 860304 


PFS Help PFIQ Next 


PFll Previous 


PFl 2 Return 



[f there are nrK>re than S documents founci, the user can scroll through the list using PF10 and PF11 . For each d 
d document found, the information displayed include : subject, status, function for which the user can access the doc- 
ument, date of action. 

If the user chooses PF5, he will first have to make a choice among categories prior to accessing forms within a 
category, a criteria entry panel is displayed requesting additional precisions on the query. Suppose the user has chosen 
General Expenses Purchase Request, the following Screen is then presented : 
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^^^^.^^^^^-^ Enter search criteria 

s 

Type : General Expenses Purchase Request 



Reference : 



Dates between : 880301 and 880314 



Amount between : > , . , . and 



Project to be charged ; 

2Q 

Subject contains \ , > , . 



25 

PF9 Help PF12 Return 



The user has to enter the criteria for searching. If he leaves a b^ank, the system interprets as the largest query, e, 
30 g. if amount is not fi!!ed-in, the system searches f ronn 0 to 9. The systerr^ begins searching when the user presses enter 
key. 

When the user has selected a document, the scree.n displayed depends on the document status. 
!f the status is "In progress*, the user is presented witt) the screen bebw 

35 . ■ . ' 



^0 



45 



SO 



55 
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Process the Document Found 

Document ; General Expenses Purchase Request JA022 In progress 
Originator : Anderson, Philip 0793 
Subject : Transport by bus 

Press one of the following PF Keys. 

PFl View the Document 

PF5 Copy the Document and create a Draft 
PF6 Cancel the Document 
PF7 Change Approver List 
PF8 Print the Docmnent 

PF9 Help PF12 Return 



The user can - view the document {data, approvers fist and comments). 

- copy the document to create a draft 

- print the document 

If he Is the originator^ he can also cancel the dccument. In this case, the user is presented the following confirmation 
panel. 



Confirm your canceling 

Document ; General Expenses Purchase Request JA022 In progress 
Originator : Anderson ^ Philip 0793 
Subject ; Transport by bus 

Confirmation will be requested and other approvers advised 
PF9 Help PF12 Return 



Pressing PF7 in 'Process the document found" menu albws the originator or an approver v^o has already acted 
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on the documGnt to change the approver Wst as he could have done when originating the document or acting upon the 
document. 

When changes are prepared, the system displays ttie following panels. 



— p.,,*^ Resend after changing approver list 



Document 
Originator 
Sub j ect 

PFl Resend 



General Expenses Purchase Request JAQ22 In progress 



Anderson^ Philip 
Transport by bus 



0793 



PF7 Change approver list 



FF9 Help PF12 Return 



If all changes are correct, the user can press PF1 and the document proceeds with the new approver list. 
PF12 will cancel all the changes. 

H the status of the document is not "In progress*, the available actions are different as shown hereafter. 



Process the Document Found 



Document : General Expenses Purchase Request JA022 Executing 
Originator : Anderson ^ Philip 0793 
Subject : Car transportation 



Press one of the following PF Keys. 



PFl View |he Document 

FF4 View the Document Fol low-Up 
PF5 Copy the Document and create a Draft 

PF8 Print the Document 



PF9 Help PF12 Return 
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10 



The user can - view the ctocument {data, approver list and comments). 

- cx)py the document to create a draft 

- print the document 

Fotlow-up information may also be given when the user presses PF4. These information indicate what action are 
being taken by the person who has to process the document, For example, for a purchase request, the system will 
Keep track and report for orders sent to the suppliers, indicate the supplier delivery date, the quantity already received, 
etc... 

All above disclosed consulting operations are summarized In the self explanatory flow chart of Figure 12. 
Any user can access the list of documents awaiting someone else's action by pressing PF5 on SEALING Main 
Menu. The following is then displayed. 



15 



20 



25 



30 



$6 



40 



Look awaiting someone else's document 



Enter or modify the user id and node (if different from this node) 



Press Enter to validate* 



User id : DUPDNT Node : LGEVM2 Name : Dupont, Philippe 



Type Qt DQQm^nt 

General Expenses Purchase Request 
General Expenses Purchase Request 
Travel Request 

General Expenses Purchase Request 



JAD79 
JA092 
T56435 
JB435 



ENTER 



FFIO Next 



FFll Previous 



PF12 Return 



The user has to fill In the userid fiefd and press enter, If userid Is not knov^^, an error message is displayed, tf 1 1 
the userjd is Itnown, the system looks for documents awaiting action and give the references. For obvbus security 
purposes, no further information alxjut document can be obtained. 

As already mentioned an approver designation, could be delegated from one user to another under predefined 
cor^ditbns. The user can access this part of the system by pressing PF7 the SEALING Main Menu or directly typing 
SEALING DELEGATE as a command. 

He Is shown the screer^ below. 



50 



5$ 
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Delegate or Retrieve Approval Authority 



For entering or modifying the userid and node (If different 

from this node) of the person you wish to delegate your authority to. 



Enter your own userid and node to retrieve your function. 



Press Enter to validate. 



Function Manager 



mi 



Userid 



VOIRON 



node 



LGEVM2 



name : Voiron, Jean 



function IBH Employee 



Userid : MARIN^^ node : I^EVH2_ name : Harln, Pierre 



PFl Search PF5 Previsions PF9 Help PFIO Next PFll Previous PF12 Return 



The screen contains the list or functions said user is titutar for, presently. The userid \Miich is indicated for each 
function is the userid of the person v^^o is actually acting for this function. One can change this userid, either to indicate 
a delegation or to put his own userid and retrieve his authority. 

For certain functions, delegation may not be allowed. The user cannot use this screen to delegate. He has to ask 
the tunctron responsible (e.g. Financial Department) to register the delegaticffi. However, the user can retrieve his 
authority lor ^y lunctbn. 

It is also pc^slble to blank the userid field. In this case, the system considers the user as absent. This feature will 
be used to bar access to the document for instance when an approver is acting on it. So, originators and approvers 
will be informed and will be able to react to this situatbn. 

To validate his entries, the user has to press the enter key 

Using PF1 allows the user to search for the userid of someone whom he knows only by his name or nickname. 
The user can press PFS to enter delegation previsions. He is shown the screen in which he can type prevision dates 
for his delegations. 

in this case, the delegation Is not activated immediately, but will be automatically set by the system at the selected 
date. The above described delegatiOTi process is summarized in the flow chart of Figure 13. 

In a large company environment, temporary general machine delegation may be required for replacing someone 
absent for vacation or for any other reasons. Under these circumstances stored data and any information bebnging 
to one user need be transferred to another user (assignee). This is achieved, in VM environment, by transferring a VM 
machine from CMie individual to another Under these circumstances however the signature delegation should barred 
unless formally requested. 

The user can access this application by pressing PFS in the SEALING fytein Menu or directly typing SEALING 
EASPRET as a command. The following screen is then presented. 
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Transferred VM 


; Userid .... VOIRON 








Serial number , 025456 




Department * . 0650 






Type his serial number . or Press PFl to search by name* 


Press ENTER to 


validate PF12 Return 



The user has tofilhin the serial number of the receiving persoi (assignee). If needed, PF1 may provide help. When 
right identification of the receiving person has been given, the screen below is displayed. 
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Transfer your VH Userid and Password 


Trfflsf^rr^d VM Vs^^id : User id . , . . 


VOIRON 




Voiron, Jean 


Serial number . 


025456 


Department * . . 


0650 


Sfi.c^iy-tog,,P^r5Qn : Serial number . 


079954 






Department . , ^ 


0790 




du 9/06/88 au 16/06/88 


Indicate a protection code which will be asked when retrieving your 


VM isachine (It will not appear when typed) 




Tvpe It twice for conttGl : 

— > 




PF9 Help PF12 Return 





The user can see the complete identification of the chosen person. He can type an optional comment and he has 
to type twice a protection code which does not appear when typed. This code will be required for canceling the machine 
transfer. 

The screen below is shown to the user when he pressed PFS on SEALlf^G Main Menu or typed SEALING EA- 
SPRET on the command line and when the VM has previously been declared as transferred. 
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Retrieve your VH 


Userid - 










Trans fwr^d VM Usferid 


: Userid , . . . 


VOIRON 






Owner 


Voiron, Jean 






Serial niMober . 


025456 






Department. , . 


0650 






Transfer date , 


880609 






Transfer time * 


214759 






Serial number . 


079954 








MILON 






Department* * . 


0790 




Transfer reason . . 


absent from 9/06/86 to 16/06/88 


Indicate the protection code typed when you transferred 


your VM 


(It will not appear when typed) 


-> ( 


0 attempts 


PF9 Help PF12 Return 







To cancel his transfer, the user has to type the protection code he selected when registering the transfer. 

Having thus described from a technical as well as functrona! standpoint, the means involved in this tnventlc^, one 
may therefore fuliy comprehend the approval system operation. Approval system operations has however bean sum- 
marized in Figures 14 tiirough 17, and Function management in Figure 18. 

Represented in Figures 1 4 through 16 are, the means involved In the determination of the iist of approvers, Obvi- 
ousiy, the system has been limited to simple cases to simplify explaining the operation. One assumes the filled-in 
document (e.g. Purchase Order) includes a Project code, a Purchaser code and an Amount of expenses set by the 
purchase requesting user. The software means uses the project code reference to address a first specific function 
table {F^MANADI ) and fetch the reference of the company department in charge of said project therefrom. Should, in 
addiibn, the purchase value exceed a threshold {1 0000), a second table (FaMAN AD2) needs be addressed. Also, due 
to the type of document invoJving expenses, the bgic adds an Investment Responsible (INVT) to the list of required 
approvers. Same applies to Purchaser (PURC). The system loads the information into two separate tables located in 
the document originator VM user's machine memory designated as FUTU and DONE respectively The DONE table 
contains so calied ^shadow^ approvers or virtual approvers whom the system m\\ enable readonly access to the cor- 
responding document. As already mentioned, once initiating the approval process, the originator may amend the list 
of approvers up to a certain extent based on predefined rules. For instance, deletion of a first line manager from the 
fist of approvers will trigger automatic Insertion o1 the second line manager, and so on. 

Then, the originator sending decision has the effect to unload the first approver references from FUTU table into 
a NEXTWAIT table while the others are loaded into a NEXTFUTU table in the preset ordered list, boih tables NEXT 
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being in ttie user's VM machine. The shadows are loaded into NEXDONE table. The above mentioned tables wilt be 
used by the system for building and updating the corresponding SQL data base tables, i.e. APPFUTU, APPWAIT and 
APP[X)NE of the SEALBDA machine. 

The SEALING system aiso controis mailing approval requests to designated approvers whose action are controlled 
s as represented in Figure 16. 

The designated approver in NEXTWAIT gets access to the data in the corresponding SQL/DS t^les in its own 
VM machines into FUTU, WAIT and DONE tables. Then NEXTFUTU. NEXTWAIT and NEXT DONE are set from FUTU. 
WAIT and DONE tables respectively. These tables contents are used by current approver to perform and record the 
folbwing c^erations: 

10 

Approver list modificaticxi: the approver may amend the list as the originator was able to do, 

Mcdification to approval process: the system controlled by any amendment to the data of document due to current 
approver, amends the approval path accordingly, and 

15 

Approver validation: compliance test with the approver's designation rules Is performed. 

Tables updating are performed, i.e. once current approval is executed, a shift is q^erated with next approver in 
NEXTFUTU being shifted into NEXTWAIT 

20 Once fonA^arded. the current approval data are used to update the SQL/DS tables through add, modify or delete 

operations. They are then available for next approver's action and so txi. 

A fairly high security level has been provided in ^is invention to limit false approvals due either to human error or 
to voluntary operation. First, one should notice that approval, i.e. insertion of a "Y" or "N"* flag into a predetermined 
field characterizing the considered document Is inserted into the SQiyDS Table APPDONE otherwise accessible to 
the user on a Readonly basis (see MVSIGN AT in Figure 6). Second, said ''signature'* or approval insertion is operated 
only upon execution of a predetermined SOL command Involving a signature validity check. The flow chart of such a 
signature validation operation is illustrated In Figure 17. The SOL command triggered by the MYSI GNAT order accesses 
various SQL tabies to gather data stored therein to ensure that the user presently trying to approve or disapprove is 
entitled to do so. First APPWAIT table is accessed to ensure that the considered document defined by typdoc/refdoc 

30 is waiting therein. Function defined by Typfun/Reffun shoudi also match with user's function, cross-checked with func- 
tion references and acting hab^litation as provided by FUNCTION Table, also, since VM machines might be transferred 
from one user to another (and recorded in INPRET Table accordingly), coinciding userid/nodeid with present user are 
checked. Then insertion into APPDONE Table, together with data and time are enabled upon a positive signature 
validaiEon test result 

35 As mentioned, the population of users attached to the same approval system is managed in an unique SQL tabie, 

i.e. the FUNCTION Table, as represented in Figure 1S. For each function, i.e. Manager, Purchaser, etc... a ^^L view 
is defined to limit any user's access to the corresponding function, assuming he had been "granted" (SQL terminology) 
access. The system is made to grant access to a function 'owner* responsible for creating and managing titular des- 
ignation within each function. Some functbns and titulars may already be known to other systems (e.g. within a con- 

40 ventional personnel department data base). In that case, Function tabie updating are directly performed by a program 
linking both involved data bases. A similar ^proach is also used tor setting and maintaining the so called specific 
characteristb table. 



45 Claims 

1. A system for controlling the processing and routing of a user originated document requiring electronic approval by 
selected system users, in an electronic mailing system including terminals (T1 . T2. T3) attached to a digital network, 
user's Virtual Machines (VM) including computer means, memory and software facilities assigned to individual 
^0 users, each user being assigned at least one job or function within the populatic^ of system attached users, and 

software controlled computer means for generating, processing and monitoring electronic ckx;uments to be mailed 
from any terminal to any user for approval, sakJ approval system including means for scheduling approval tasks 
for users and means for defining a path or route specification tor any document to be approved by various users, 
said means for scheduling approval and specifying a path being characterized in that it includes ; 

55 

first storage means (SEALDBA Machine; Function Tables) and terminal ccMitroHable means for storing and 
updating prestored function tables wherein each system user's function and address are identified ; 
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secc^d storage means (SEALDBA Machine; Document tables) for storing document forms into data base 
tabtes, in Structured Query Language (SQL) form, and software operated computer means for linking said 
tables togelhar m a tree-shaped arrangement ; 

third storage means (SEALDBA Machine Approval Tables) for storing predefined approval rules based on 
user's function and document forms contents ; 

terminal controllable means (User's Virluai Machine) for selecting, accessing, filllngnn, processing and maiiing 
any selected form whose contents is lo be subjected to approval; 

first software controHed computer means sensitive to said mailing for addressing said function tables and, 
based upon said approval rules, for dynamically delermining the approval path or route amCTig the system 
attached users, said means for determining the approval route including : 

second software com rolled computer means sensitive to said approval rules for reading document data by 
addressing specific SQL data tables; 

third software controlled computer means {FQMANAD1 , FaMANAD2) sensitive to said read data to address 
said function tables and fetch approvers' references therefrom ; 

fourth software controlled computer means sensitive to said stored approval rules for listing said approvers' 
references in a predefined sequential order into an approval list ; and, 

fourth storage means for storing said approval list into a table (FUTU) whereby said approval pa^^i Is determined 
and used for monitoring the mailing and processing of said filled-in form accordingly, 

A system according to claim 1 further including fifth software controlled computer means sensitive to read data for 
generating an additional list of users assigned access to correspc^ding dcx;ument data on a read-only basis ; and 
storage means for storing said additional list into a table (DONE). 

A system according to claim 2 further including : 

display means for displaying said FUTU table to the document originating user ; 

sixth software ccxitrolled computer means sensitive to said stored rules for enabling said originating user to 
check and amend said FUTU table ; and. 

seventh software controlled computer means for initiating the document approval process upon completicn 
of said checking. 

A system according to claim 3 wherein said means for initiating the document approval ptKx;ess include ; 

eighth software controlled computer means for loading first approver in the FUTU table into a prestored NEX- 
TWAIT table and loading remaining FUTU table contents into a prestored NEXTFUTU table ; and, 

ninth software controlled computer means sensitive to NEXTWAIT table contents to mail a predefined message 
to the corresponding approver*s VM-machine. 

A system according to claim 4 including : 

tenth software controlled computer means tor unloading said DONE table into a prestored NEXT DONE table 
within VM user's machine ; and 

eleventh software controlled computer means for unloading NEXTFUTU, NEXTWAITand NEXTDONE user^s 
tables into prestored SQL tables APPFUTU, APPWAIT and APPDONE respectively. 

A system according to claim 5 v\^erein said means for managing appropriate approvals include : 
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user's terminal controHabie means for requesting access to system SQL tables ; 

system controllable means for accessing stored function tables, companng terminal user's identification to 
approver's as stored into said function tables and, upon positive check, unloading contents of predefined fields 
5 of APPFUTU, APPWAIT and APPDONE SQL tables into user^s VM madiine tables FUTU, WAIT and DONE 

respectively ; 

system controllable means sensitive to said user's machine tables contents for displaying preselected data 
from ckjcuments waiting for said user's approval ; 

10 

user's terminal controllable means for selecting one of said documents whereby said selected document Is 
being displayed to said user ; and 

terminal controllable means for said user inserting approval or disapproval decision {signature) Into a prede- 
is fined document field. 

7. A system according to claim 6 wherein said means for inserting user's decision include system ccntroHed decision 
(approval) validation means and, upon correlative positive validity check, means sensitive to said validation means 
for writing user's decision into SQL table APPDONE othenwise accessible on a read-only basis. 

20 

8. A system according to claim 7 wherein said approval validation means include software controlled computer means 
tor fetching a system prestored SQL command and means sensitive to said command for triggering said approval 
validity check. 

2S 9. A system according to claim 8 \Mierein said approval validation means include : 

software controlled computer means for addressing the APPWAIT system table and checking presence of the 
considered document therein; and, 

30 software controlled computer means for addressing APPWAITing document data and function table to check 

concurrence with operating user's identification. 



Patentanspruch© 

1. System zum Steuern der Verarbeitung und des Weiterleitens eines vom Nutzer erzeugten Dokumentes, das eine 
elektronische Genehmigung durch ausgewahlte Syslemnutzer erfordert, in einem elektronischen Postsystem mit 
Datenstationen (Tt, 12. T3), die an ein digilales Netz angeschlossen sind, Virtuellen Maschinen (VM) des Nutzers 
mit Computermltteln, Speicher und Softwareelnrichtungen, die individuelien Nutzern zugeordnet sind, wobei jedem 

40 Nutzer mindestens ein Jcb oder eine Funktion innerhalb der Gesamtheit der an das System angeschic^senen 

Nutzer zugeordnet ist, und durch Software gesteuerten Computermitteln zum Erzeugen, Verarbelten und Uber- 
wachen elektronischer Dokumente. die von irgendeiner Dstenstation an irgendeinen Nutzer zur Genehmigung zu 
sender sind, wobei das Genehmigungssystem Mittel zum Planen der Genehmigungsvorgange fOr Nutzer und 
MitteS zum Definieren eines Pfades oder einer Leitwegspezifikation fur irgendein durch verschiedene Nutzer zu 

45 genehmigendes Dokument umfaBt, wobei das mxe\ zum Planen der Genehmigung und zum ^geben eines Pfa« 

des dadurch gekennzetehnet ist. dafi es folgendes umfa3t; 

erste Speichermittel (SEALDBA-Maschine; Funktionstabellen) und durch die Datenstation sleuerbare Mittel 
zum Speichern und Aktualisieren vorher gespeicherter Funktionstabellen, in denen die Funktion und die 
60 Adresse jedes Systemnutzers gekennzeichnet sind; 

zweite Speichermittel (SEALDBA-Maschine; DokumenttabelSen) zum Speichern von Dokumentformularen in 
Datenbanktabellen im Formuiar der Structured Query Language (SQL) und durch Software betriebene Com- 
putermitte! zum Verbinden der Tabellen miteinander in einer baumfdrmigen Anordnung; 

55 

dritte Speichermittel {SEALDEA-Maschine; Genehmigungstabellen) zum Speichern vordefinierter Genehmi- 
gungsregeln basierend auf der Funktion des Nutzers und dem Inhalt der Dokumentformulare; 
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durch die Datonstation steuerbare Mittel (Viftuelte Maschfne des Nutzers) ztxm Auswahlen, Zugrsifen, Aus- 
f Qllen, Verarbeiteo und Senden irgandeines ausgewahlten Formulars, dessen inhalt genehmlgungspflichtig ist; 

erste durch Software gesteuerte Computermittel, die auf das- Senden anspr^hen, um die Fur^ktionstabelSen 
zu adressieren und um, basiarend auf den Genehmigungsregeln, den Genehmigungspfad Oder Leitweg zwl~ 
schen den an das System angeschlossonen Nutzem dynamtsch bestlmmen, wobei das Mittel zum Bestim- 
men des Genehmigungsleitweges lolgendes umfaBt: 

zweite durch Software gesteuerte Compute rmittei. die auf die Genehmigungsregeln ansprechen. um Doku- 
mentdaten durch das Adressieren spezieller SQL-Datentabellen zu lesen; 

dritte durch Software gesteuerte Computemime! (FQMANAD1, F^MANAD2), die auf das Lesen der Daten 
ansprechen, um die Funktionstabellen zu adressieren und Verweise der Genehmiger darausabzurufen; 

vierte durch Software gesteuerte Compiitermittel, die auf die gespeicherten Genehmigungsregeln anspre- 
chen, um die Verweise der Genehmiger in einer vordefinierten sequentietien Reihenfolge in eine Genenmi- 
gungsiiste aufzufisten; und 

viarte Speichermittel zum Speichern der Genehmigungslisle in eine Tabelle (FUTU), wodurch der Genehmi- 
gungspfad bestimmt und verwendet wird. um das Senden und Verarbeiten des ausgetulften Formulars ent- 
sprechend zu ObenA/achen. 

System gemaf3 Anspruch 1 , das weilerhin tunfle durch Software gesteuerte Computermittel umfaBt, die auf das 
Lesen von Daten ansprechen, um eine zusatzNche Liste von Nutzern zu erzeugen, denen der Zugriff auf enlspre- 
chende Dokumentdaten auf einer NurlesebasBZugeordnet ist; und Speichermittal zum Speichemderzusatzlichen 
Liste in eine Tabeile (CXDNE). 

System gemaB Anspruch 2, das weiterhin folgendes umfaf3t: 

Anzelgemitle! zum Anzeigen der FUTU-TabeHe an den das Dokument erzeugenden Nutzer; 

sechste durch Software gesteuerte Computemilttel die aut die gespeicherten Regein zum Aktivieren des 
erzeugenden Nutzers ansprechen, um die FUTU-Tabeile zu uberprufen und zu erganzen; und 

siebente durch Software gesteuerte Computermittel zum Einieiten des Dokumentgenehmigungspfozesses 
nach Abschlu3 der Uborprufung. 

System gemaB Anspruch 3, wobei die Mittel zum Einieiten des Dokumentgenehmigungsprozesses folgendes 
umfassen: 

achte durch Software gesteuerte Computemiittet zum Laden erster Genehmiger In der FUTU-Tabelle In eine 
vorhef gaspaicherteNEXTWAIT-Tabelle und Laden des verbleibendan Inhalts der FUTU-Tabelle in einevorher 
gespeicherte NEXTFUTU-Tabelle; und 

neunte durch Software gesteuerte Computermittel, die aul den Inhalt der NEXTWAIT-Tabelie ansprechen, um 
erne vordefinierta Nachricht an die entsprechande VM-Maschine des Qenehmigers zu senden. 

System gemaQ Anspruch 4 mit: 

zehnten durch Software gesteuerten Cc^putermitteln zum Ent laden der DONE-Tabelle in eine vorher gespei- 
cherte NEXTDONE-TabeHe innerhalbder VM-Maschine des Nutzers; und 

elften durch Software gesteuerten Computermittein zum Entladen dar NEXTFUTU-, NEXTWAIT- und NEXT- 
DONE-Tabellen des Nutzers in vorher gespeicherte SQL-Tabellen APPFUTU, APPWAIT bzw. APPDONE. 

System gemaB Anspruch 5, wdael die Mittel zum Verwatten entsprechender Genehmigungan folgendes umfassen: 

durch die Datenstatlon des Nutzers steuerbare Mittel zum Anfordem des Zugriffs auf Systam-SQL-Tabellen; 
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durch das System steuerbare Mittel zam Zugreiten auf gespetcherle Funktjonstabellen, zum Vergleichen dor 
Kennzebhnung der Datenstation des Nutzers mit der des Genehmi gers, wie in den Funktionstabellen gespel- 
chert, Ltnd, nach posrtiver Uberpruf ung. zum Entladen des Inhalts vordefmierter Felder der APPFUTU-, APR- 
WAIT- und APPDONE-SQUTabehen in VM-Maschinentabellen FUTU, WAIT bzw. DONE des Nutzers; 

5 

durch das System steuert)are Mittel, die auf den Inhalt der Maschinentabellen des Nutzers ansprechen, urn 
vorher ausgewahlte Daten von Dokumenten, die auf die Genehmigung des Nutzers warten, anzuzeigen; 

durch die Datenstation des Nutzers steuerbare MItlei zum Auswahlen eines der Dokumente, wodurch das 
10 ausgewahlte Dokument dem Nutzer angezeigt wird; und 

durch die Datenstation steueitare Mittel ZLim Einfugen derGenehmigungs-oder Nichtgenehmigungsentschei- 
dung (Unterschrift) des Nutzers in ein vordefiniertes Dokumentleid, 

?5 7. System gemaB Anspruch 6, wobei die Mittel zum EinlQgsn der Entscheidung des Nutzers durch das System 
gesteuerte Mittel zum Prufen der Gultigkeit der Entscheidung (Genehmigung) umlassen und, nach erganzender 
positiver Uberprufung der Gultigkeit. Mrttel umfassen, die auf die Mittel zur GQltigkeitsprufung ansprechen, um die 
Entscheidung des Nutzers in die SQL-Tabelle APPDONE zu schreiben, auf die sonst auf einer Nurtesebasis zuzu- 
greifen ist. 

so 

8. System gama6 Anspruch 7, wobei die Mittel zum Prufen der Gultigkeit der Genehmigung durch Software gesteu- 
erte Computermittel umfassen, um einen im System vorher gespeicherten SQL-Befahl abzufragen, und Mittel, die 
aul den Befehl zum Ausk>sen der Uberprufung der Gultigkeit der Genehmigung ansprechen. 

ss 9. System gemaB Anspruch 8, wobei die Mittel zum Prufen der GOttigkeit der Genehmigung tolgendes umfassen: 

durch Software gesteuerte Cc«nputermitte! zum Adressieren der APPWAIT-Systemtabelle und zum Uberpru- 
fen des Vorhandenseins des betrachtaten Dokumentes darin; und 

30 durch Software gesteuerte Ccmputermittel zum Adressieren von Dokumentdaten In APPWAIT und der Funk- 

tionstabelle zum Uberpruf en der Dbereinstimmung mit der Kennzeichnung des betreibenden Nutzers. 



Revendications 

35 

1 . Sysleme destine a commander le traitement et I'acheminement d'un document originaire d'un utilisateur necessi- 
tant une approbation electron ique par des utilisateurs choisis du systems, dans un syst^me de courrier electronique 
comprenani des terminaux (T1, T2, T3) connectss a un reseau numerique, des machines virtuelles d'utllisateur 
(VM) comprenant un moyen d'ordinateur, des amenagements de memoire et de logiciel affectes a des utUisateurs 

40 individue^s, chaque utilisateur etant aftecx^ a au moins un travail ou une fonction k I'interieur de la population 

d'utilisateurs cainect^e au syst^me, et un moyen d'ordinateur command^ par togiciel destind k g^n^rer, traiter et 
surveifler des documents electroniques devant §tre envoyes a partir d'un terminal quelcwique vers un utilisateur 
quelconque pour approbation, ledrt syst^me d'approbatbn comprenant un moyen destine h planifler les t^ches 
d'approbation pour les utilisaleurs et un moyen pour definir une specification de trajet ou cheminement pour tout 

45 document a approuver par les divers utilisateurs, ledit moyen desttrt^ ^ planifier les approbations et h specifier un 

trajet etant caractirla^ en ce qu'ii comprend : 

un premier moyen de memorisation (machine SEALDBA. tableaux de fonction) et un moyen pouvant etre 
command^ par terminal destine h m^moriser et a mettre h jour des tableaux de fonction prdenregistr^s dans 
so lesquels sOTit identifi^es chaque fonction et adresse d'utllisateur du systems, 

un second moyen de memorisation (machine SEALDBA, tableaux de document) destine h m^moriser des 
tormulaires de document dans dss tableaux de base de donnees, sous forme de langage de requites struc- 
turves (SOL) et un moyen d'ordinateur fonctionnant par logiciel destine k relier ensemble Jesdits tableaux 
55 dans un agencement arborescent, 

un troisi^me moyen de memorisation (machine SEALBDA, tableaux d'approbation) destine a memoriser les 
regies d'approbation pr^d^finies bashes sur ia Ic^ction de i'utiltsateur et conter^us des formulaires de docu- 
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ments, 

un moyen pouvant etre ccxnmande par lerminai (machine virtuelle d'utilisatsur) destine k chotsir, acceder 
rempiir, traiter, et exp^dier tout formutaire choisi dc^it le contenu doit dtre soumis k approbation, 

un premiermoyen d'ordinateur command^ par Ic^iciel r^pc^dant audit courrier afin d'adresser lesdits tableaux 
de fonction et base sur lesdttes regies d'approbation, afin de determiner de fa^on dynamique le trajel ou 
chemrnement d'approbation parmi les utilisateurs relics au syst^me, ledit moyen destine k determiner le che- 
minement d'approbation comprenant : 

un second moyen d^ordinateur ccntrole par logiciel repondant auxdites regies d'approbation pour lire les don- 
nees de document en adressant des tableaux de donnees SQL, 

un trofsi^me moyen d'ordinateur controle par logiciel (FQMANADi , FaMANAD2) repondant auxdites donnees 
lues pour adresser lesdits tableaux de foictione et r^cup^rer las r§f ^rences d'approbateurs a partir de ceux-ci. 

un quatrieme moyen d'ordinateur command^ par iogiciel repondant auxdites fugles d'approbation m^moris^es 
afin d'etablir la liste desdites references d'apprdDateurs dans un ordre sequential predefine en une liste d'appro- 
bation, et 

un quatrieme moyen de mdmorisation afin de m^moriser ladite fiste d'apprc^atioi en un tableau (FUTU) par 
leque! ^edit trajet d'approbation est determine et utilise en consequence pour surveiHer I'envol et le trailement 
dudil formuiaire rempli. 

Syst^me selon !a revendication 1 comprenant en outre un cinqui^me moyen d'ordinateur command^ par iogiciel 
repondant aux donnees lues afin degen^rer une Ifste supplemental re d'accesaffeclesaux utilisateurs aux donnees 
de document correspondantes sur une base de lecture seule, et un moyen de memorisation destine a m^moriser 
ladite liste supplemental re en un tableau (DONE). 

Syst^me selon la revendication 2, comprenant en outre : 

un moyen d'affichage pour afficher ledit tableau FUTU de t'utilisateur ^metteur du document, 

un sixi^me moyen d'ordinateur command^ par bgictel repondant auxdites rdgles m^moris^es afin d'autoriser 
ledit utiltsateur emetteur a verifier et modifier ladite table FUTU, et 

un septleme moyen d'ordinateur commande par bgiciel destine a initialiser ie processus d'approbation de 
document apres execution de ladite verification. 

Systeme selon la revendication 3, dans lequel ledit moyen d'initialisation du processus d'approbation du document 
comprend : 

un hutti^me moyen d'ordinateur commande par logiciel destine ^ charger ie premier approbateur dans la table 
FUTU a rint^rieur d*un tableau NEXWAIT prememorise et a charger ie contenu restant du tableau FUTU k 
rint^rieur d'un tableau NEXTFUTU pr^m^moris^, et 

un neuvieme nrK)yen d'ordinateur command^ par bgiciel repondant au cc^itenu du tableau NEXWAIT afin 
d'envoyer un message predefini a la machine virtuelle de Papprobateur correspondante, 

Systeme selon la revendication 4, comprenant : 

un dtxi^me moyen d'ordinateur commands par logiciel destln^ k decharger ledit tableau DONE k I'lnt^rieur 
d'un tableau NEXTDONE prememorise compris dans une machine d'utllisateur de machine virtuelle, et 

un onzieme moyen d'ordinateur command^ par logiciel pour decharger les tableaux NEXTFUTU, NEXT WAIT 
et NEXTDONE d'utiiisateur dans des tableaux SQL pr^m^moris^s APPFUTU, APPWAIT et APPDONE res- 
pectivement. 
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Syst&me selon ia rQvendicatbn 5, 6am Sequel jedit moyan destine a g^rer les approbations appropri^es oomprend : 

un moyen pouvant dire commande par un terminal d'ulilisateur afin de demander i'acces aux tableaux SQL 
du syst^me, 

un moyen pouvant §tre command^ par !e syst^me destine k acc^der au tableau de fonctions m6moris6es, k 
comparer ndentification de f'utilisateur de terminal a celte de i'approbaieur tel que menrKjrisee dans lesdits 
tableaux de fonctbns et, apr^s une v^rrficalfon positive, d^charger le contenu des champs pr§d6finis des 
tableaux SQL APPFUTU, APPWAIT ei APPDONE dans ies tableaux de machine virtuelle d'utllisateur FUTU, 
WAIT et DONE respectivement, 

un moyen pouvant etre commande par \e systeme repondanl audit contenu des tableaux de machine de 
t'utilisateur pour afficher tea donn^es pr^seiectbnnees a partir de documents attendant ladite apprc^atfon 
d'utHlsateur, 

un moyen pouvant etre command^ par le terminal d'utilisateur afin de selectbnner Tun desdits dcx;um6nts par 
(equel ledit document choisi se trouve affich§ audit utilisateur, et 

un moyen pouvant dtre commande par terminal afin que ledit utilisateur insure sa decision d'approbation ou 
de d^sapprobatbn (signature) a I'interieur d'un champ predefini du document. 

Systeme selon la revendication 6, dans lequel ledit moyen destine a Inserer ia decision de Tutilisateur comprend 
un moyen de validation (approbation) de decision command^ par ie systeme et, apr^s une verification de validity 
positive en correlation, un moyen repondant audit moyen de validation afin d'ecrire la decision de I'utilisateur dans 
un tableau SQL APPDONE accessible autrement sur une base de lecture seulement. 

Systeme selon la revendtcatton 7, dans lequel \b6\\ moyen de validation d'approbation comprend un moyen d'ordi- 
nateur command^ par togiciel destine k r^cup^rer un ordre SQL pr^m6morisi du systfeme et un moyen repondanl 
audit ordre pour d^cfencher ladite verification de validite d'approbation. 

Systeme sefon la revendication 8, dans lequel ledit moyen de validation d'approbation comprend : 

un moyen d*ordi nateur commande par iogiciel destine ^ adresser le tableau de systeme APPWAIT et a verifier 
la presence du document consider^ dans ceiui-ci, et 

un moyen d'ordinateur command^ par Iogiciel destine a adresser le tableau APPWAIT de donn^es et de 
fonctions du document en attente pour verifier la correspCMidance avec ridentification active de I'utilisateur. 
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